home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Jan 91 / MacApp.Tech$ 1⁄25⁄91 / 2795-Re RE(?) Pascal '9x…-Jan91 < prev    next >
Encoding:
Text File  |  1991-03-06  |  1.9 KB  |  43 lines  |  [TEXT/GEOL]
  1. Item    1926048                         24-Jan-91        18:43PST
  2.  
  3. From:   BERDAHL                         Amoco Tech, Eric Berdahl,VAR
  4.  
  5. To:     GER.XDV0002                     Germany - P1 Ges f Informatik,IVR
  6.         MACAPP.TECH$                    MacApp Technical
  7.  
  8. ------------------------------------------------------------------------------
  9.  
  10. Sub:    Re: RE(?): Pascal '9x… (long)
  11.  
  12. To All:
  13. Through some oversight on my part, a critical link in the C++ function
  14. reference returning discussion did not get sent to MacApp.TECH$.  For that I
  15. appologize.  So, for the rest of us, here goes:
  16.  
  17. The appropriate references (no pun intended) are to §12.1.1c (pp 300-303) and
  18. §8.4.3 (pp 153-155) of Ellis and Stroustrup _The_Annotated_C++_Reference_.
  19. What I wrote was reading too much into the C++ language description.  If a
  20. function returns an object, you are safe.  AT&Ts implementation of CFront
  21. generates C code that really returns void and takes a pointer to the
  22. apporpriate object as a first argument.  Thus, the calling function generates a
  23. temporary variable for the result and passes the pointer.  Observe (from Ellis
  24. and Stroustrup).
  25. Matrix operator+(const Matrix& a1, const Matrix& a2) {}
  26. generates something like
  27. void matrix_add(Matrix* __result, Matrix* a1, Matrix* a2) {}
  28.  
  29. If, however, the function returns a reference, the language description is
  30. ambiguous.  It does not guarantee anything, so the implication is not to return
  31. references to local variables.  Personally, it is exactly this kind of
  32. ambiguity that leads me to use reference returns sparingly.  Generally, I
  33. endorse reference returns only as a return from a member function (e.g. TFoo&
  34. TFoo::FooMethod()) where I can return *this. In this case, reference returning
  35. is quite convenient and easy.  In all other cases, I’m not hot on references
  36. except as local variables or const arguments.
  37.  
  38. Skimming the soup,
  39. Eric Berdahl
  40. Amoco Technology Company
  41. AppleLink: BERDAHL
  42.  
  43.